The popularity of mobile computing and networked communications devices has created a corresponding wish for the ability to deliver and receive information whenever users want from any of their disparate devices. Put simply, users want ubiquitous access to information and applications from a variety of devices, wherever, whenever, and whatever the devices' capabilities, and in addition, users want to be able to access and update such information on the fly, they want guarantees that the data is as correct and up to date as can be, and they do not wish to pre-configure or subsequently guarantee that their devices will connect via any particular network topology.
Conventionally, distributed data systems have attempted to have devices and objects share replicas of data with one another based upon a static setup among devices. For instance, music sharing systems may synchronize music between a PC, a Cell phone, a gaming console and an MP3 player. Email data may be synchronized among a work server, a client PC, and a portable email device. However, today, to the extent such devices synchronize a set of common information with each other, the synchronization takes place according to a static setup among the devices. Yet, a static setup is inflexible by definition. When these devices become disconnected frequently or intermittently, i.e., when they are loosely coupled such that they may become disconnected from communicating with each other, e.g., when a cell phone is in a tunnel, or when the number of devices to be synchronized is dynamic, it becomes desirable to have a topology independent way for the devices to determine what changes each other device needs when they re-connect to one another, or as they join the network.
Today, as shown in FIG. 1, there are various examples where a master node 100 synchronizes in a dedicated manner with a client node 110, such as when an email server synchronizes with an email client. Due to the dedicated synchronization between the two devices, the information 102 needed to synchronize between the two devices can be tracked by the master node 100. Such information 102 can also optionally be tracked by client node 110 as well, however, when the connection between master node 100 and client node 110 becomes disconnected at times, or when the number of synchronizing devices can suddenly increase or decrease, tracking the necessary information of the common information that each device needs across all of those devices becomes a difficult problem.
Current solutions often base their synchronization semantics solely on clocks or logical watermarks for a specific node (e.g., the email server), as opposed to any node. These systems can work well in cases of a single connecting node or master. However, they run into problems when the topology or pattern in which the nodes connect can change unpredictably.
Other systems build proprietary synchronization models for specific kinds of data objects, tracking an enormous amount of primitive metadata specific to the data format across the devices in order to handle the problem. For instance, to synchronize objects of a particular Word processing document format, a lot of overhead and complexity goes into representing a document and its fundamental primitives as they change over time, and representing that information efficiently to other devices wishing to synchronize according to a common set of Word processing documents. In addition to such systems being expensive and complex to build and non-extendible due to their implementation of a custom data format, such systems are inherently unscalable due to the large amounts of metadata that must be generated, analyzed and tracked.
In addition, such solutions apply only to the one specific domain, e.g., Word processing documents. When synchronization objects of all kinds are considered, e.g., pictures, videos, emails, documents, database stores, etc., one can see that implementing custom synchronization solutions based on each object type for tracking evolution of such objects across all devices in a multi-master environment is unworkable today. In this regard, such solutions inextricably link synchronization semantics with the data semantics. Thus, if the data semantics change, or evolve, such solutions fail to adapt the synchronization semantics correspondingly.
Thus, there is a need for node-independent synchronization knowledge when computers in a topology change the way they connect to each other or as the number of computers grows. For instance, with a media player, it might be desirable to synchronize among multiple computers and multiple websites. In most instances, most applications can only synchronize data between a few well-known endpoints (home PC and media player). As the device community evolves over time for a user of the media player application, however, the need for data synchronization flexibility for the music library utilized by the devices increases, thereby creating the need for a more robust system.
The need becomes even more complex when one considers today's network data synchronization employed for servers and Web services. As mentioned, conventional synchronization systems presume a particular network topology, and when it comes to Web services, a consuming device is closely coupled with the server endpoint. While this can work effectively for a single consuming device that does not require a lot of processing and that does not generate a lot of network traffic, when a social networking service may have millions of users at a time, one can quickly see that the conventional model faces significant scaling issues. Such issues result because server resources are costly and can become scarce at times of high demand and because the data shared between disparate devices is often not a compact representation of what the device knows or wants to learn.
Thus, what is desired is an efficient set of commands among server and client devices, applications and services that can be used in a multi-master synchronization environment where network topology and connectivity among devices is unpredictable, where any device can synchronize with any other device to reduce overall load on particular server resources and network bandwidth caused by synchronizing devices. What is further desired is a synchronization layer “in the cloud” from the perspective of loosely coupled devices, applications and services, which enables synchronizing entities, in effect, to offload synchronization handling and processing when they become connected to a network.
In addition, conventional synchronization models also do not adequately address the off-line problem, i.e., today, when a device becomes disconnected, synchronizing applications on the device also fail because their synchronization capability depends on a connection to a corresponding server.
Or, even where an off-line experience is permitted, it is the result of custom application code that is predicated on knowledge of a preset network topology for the off-line experience. In other words, for an off-line email client that goes back on-line and attempts to synchronize, it can synchronize only because the email client explicitly knows about the server in advance. Extending the example further, if the email client has version 782 of the email data and the email server has version 789 of the email data, then the email client can obtain version 789 held at the server because the email client explicitly knows about the server by pre-configuration. Yet, if the email client comes into communicative contact with a laptop that also happens to have a copy of the exact same version 789 of the email data held by the server, today, the email client cannot synchronize with the laptop instead of the server as part of a flexible offline experience. Thus, the complexities of a multi-master synchronization environment have yet to be adequately addressed in connection with an off-line application experience.
The above-described deficiencies of today's synchronization systems are merely intended to provide an overview of some of the problems of conventional systems, and are not intended to be exhaustive. Other problems with conventional systems and corresponding benefits of the various non-limiting embodiments described herein may become further apparent upon review of the following description.